Lambda the Ultimate

I have seem many posts about technology that lets you change the behavior of a program with changing the code. They claim that changes to production environments can be made as easily as changing a config file. Many times these config files hold import details like database queries.

My question is, what is considered source code?

Obviously, anything written in a programming language and compiled is source code. But what about non-compiled code?

Are SQL statements considered source code? What if they are in a config file?

Should the database structure be considered "source code"? What about the stored procedures it contains?

How about a config file that makes minor changes the way the program works? For example, using a different factory class based on a flag.

What if the changes are major? For example, one that injects code in the fashion used in Aspect Oriented Programming.

This is important because, in the real world, all changes to source code need to be documented and tested.

This has been discussed before on LtU, but I don't think you can add new messages to threads in the "classic" section. I came across this presentation while I was contemplating ways to generalise a SAX-style interface to a parser I was writing and realised that I'd practically written a fold already. The API proposal is excellent and I think would make a good fit for some collections I've been thinking of writing for Tcl (I'd adapt the fold to be able to optionally make use of Tcl's event loop for doing traversals in the background, and use Tcl's break/continue/error exceptions rather than an explicit continue/don't continue indicator in the result). However, I thought I'd just check to see whether there is any new research on this that I should be aware of. Also, I'm struggling somewhat with the Haskell code demonstrating the enumeration->cursor transform without call/cc. Specifically, I'm wondering if it would be possible to translate the example into a language like Tcl which is strict and has relatively weak support for functional programming techniques? I think I could probably get my head around the Haskell enough to try and make a cheap+dirty imperative version, but any ideas on good ways to go about it would be useful.

Over the past few months I have collected a few links for Java functional libraries (I haven't actually used any of them yet in any major project). Thought it might interest people here:


http://www.cs.chalmers.se/~bringert/hoj/ programmer (includes Java 5.0 generics support). Little documentation.


http://jakarta.apache.org/commons/sandbox/functor/ doesn't look like it is maintained, doesn't support generics. Little documentation.


http://devnet.developerpipeline.com/documents/s=9851/q=1/ddj0511i/0511i.html
library.


http://functionalj.sourceforge.net

http://www.functologic.com/orbital/

http://jga.sourceforge.net/ programming in java (includes generics). Looking forward to more documentation, perhaps better organization of the API.




Java 5.0 also has an interesting interface (same as Oz, AliceML?):
java.util.concurrent.Future with the following description:

"A Future represents the result of an asynchronous computation. Methods are provided to check if the computation is complete, to wait for its completion, and to retrieve the result of the computation"


I read one rumor (on theserverside.com...can't find it any more) that Java 7.0 will have something like C#'s delegates.


There was another comment from Javalobby.org about simulating continuation using a new library in Java 5.0 (I believe from java.util.concurrent.*)...can't find that either.



Googling for "functional c#" brings up some blog enteries where people show how to do functional style programming in C#. ACM has a couple of papers on functional programming in Java/C#, I'm trying to find those again.

Neko is an intermediate high-level dynamicly typed programming language. It has been designed to provide a common runtime for several different languages (dynamicly as well as staticly typed).

Some people were interested in Neko evolution, so I'm posting here the new features that are part of the just-released 1.2 version (see http://nekovm.org) :

• runtime exceptions : several operations that were returning "null" before are now raising an exception. This is the case for invalid function calls (not a function or invalid number of arguments), object field access (for example null.x) , array access (still null if outside of bounds) and numerical operations.
• linker : using "nekoc -link" you can now link a lot of .n bytecode files together into a single standalone .n file
• nekoboot : this utility enable you to create standalone executables from a single bytecode file
• renaming : the neko virtual machine is now named "neko" (instead of nekovm) and both neko and nekoml compilers are named "nekoc" and "nekoml". Compilers are built using nekoboot and are then standalon executables (this is more easy to use, simply "nekoc myfile.neko").
• TCO : tail recursion optimizations in Neko
• Object Prototypes : object can now have chained prototype (see Language Reference Documentation)
• standard library : added UTF8 support, improved XML parser, and other useful primitives as well
• licence change : Neko 1.2 is now LGPL while Neko 1.1 was GPL

I would like to get feeback from people that are interested in Neko. What are the features that are missing in Neko for you to target it ? Is there something in the design/other that prevent you from using Neko ? I'll work on next release to fix theses points if any.

Currently there is continuations on my TODO list.

I had first heard of Scratch as being a candidate for MIT's $100 laptopfor the third world. It appears to be a mind-meld of Squeak Smalltalk (the implementation language), Microworld Logo and the Lego Mindstorm's visual programming environment.

Here is an early paper on the language and here is the (even earlier) proposal.

There was some recent discussion on here that mostly claimed that singleton classes, assuming they had state, were bad (I'm not quite sure what a stateless singleton would be other than a different naming convention for global functions). I'm unconvinced =)

Stateful singletons still offer one advantage over straight global variables -- they have encapsulation. Granted, it's not any better than having a global object, but it does at least seem a little safer in that you can control access to it, cutting down a lot of the arguments against global variables in general. I'm not sure what nightmare scenarios people are thinking of when they say singletons can change unpredictably.

Can someone clarify?

I'm thinking of a class having C++ code something like this. For the sake of argument we'll say this is a design situation where we know we'll only need one of this class.

class DataList
{
public:
    static void AddToList(ctl_node& node);
    static void Display();
    static ListIter Begin();
    static ListIter End();
protected:
    DataList();
    ~DataList();
    static DataList& Instance();
    
    ListType nodeList;
};

DataList& DataList::Instance()
{
    static DataList theList;
    return theList;
}

void DataList::AddToList(ctl_node& node)
{
    DataList& theList = Instance();
    
    theList.nodeList.push_back(&node);
}

That's enough to see how the functions would get a reference to the one instance.

Thoughts?

In this post, Andreas Rossberg alludes to the idea of an "effect system," which annotates programs with information about what impure operations various components perform. He also says that there has been "quite some research on [effect systems] in the past 15 years." However, I've been unable to find anything interesting with Google. Could someone please point me to some good research on effect systems?

After reading the latest "Classic Papers" discussion, I thought I'd make a short list of important and enjoyable papers. Have a look and tell me if I missed some important ones.

link

Found this link on OSNews and thought i might post it here. It is an interview with Stroustrup in which he talks about his new language: C++0x. It is supposed to come out in 2009 and be the next evolution of c++, geared
towards making C++ a better language for systems programming and library building and make C++ easier to teach and learn.

Being interested in dataflow languages and hardware for almost three weeks already I found very little information about those topics. The most interesting was Wavescalar dataflow processor mainly because of recency of the work.

It seem (from Google index) that dataflow programming is somewhat out of vogue.

Anyway, do anyone have any information about dataflow language implementations and hardware support for that computing paradigm?

And why does anything dataflow based seem to be out of mainstream?